I don't know if we should exclude it. We should rather find a reasonable default value.

From the "Errors" I can deduce that there are many lint errors within this project if you enable the rule. In this case you can just disable it in tslint.json

chained property accessors or chained method calls?

also note that the corresponding eslint rule only counts method calls and not property accesses

So method calls on their own line if the chain length--including prop accessors--is greater than n? Or should chain length include method calls only?

I guess method calls only is the best to start with. Otherwise you'll get a lot more errors with little benefit.
For example chai assertions:

expect({a: 1}).to.not.have.property('b');

Good point. Your single-line chai example looks fine to me, but if it had a third call I'd want each call to be on its own line:

expect({ a: 1 })
    .to.not.have
    .property('b').more.accessors // Should this be okay?
    .methodCall(1);

And this makes me realize that my scheme of counting \n chars is not very flexible... Do you have advice on how to approach this problem?

expect({ a: 1 })
    .to
    .not
    .have
    .property('b').more.methodCall(1); // Will fool the walker I think...

I guess it's best to check if there is a newline after the method call. No counting at all.

// allowing
expect({ a: 1 })
    .to.not.have.property('b');
// disallowing
expect({ a: 1 }).to.not.have
    .property('b')

The only exception is the first method call:

// not allowed
foo.bar()
    .baz();
// same with
this.bar().
    .baz();

// allowed
foo
    .bar()
    .baz();

Okay nice, that's a much better solution. I have only one thing I'd change in your examples, and it's purely stylistic. I think property accessors between method calls look better like this:

expect({ a: 1 })
    .to.not.have
    .property('b');

... the condition being that prop accessors between method calls cannot be on the same line as either method call. I think? It may be too convoluted for a config option. I think this is the behavior I would want in the default setting, though.

what's that condition supposed to do? If nextNode is a PropertyAccessExpression it will never be ThisKeyword.

this could just be a while loop

I don't think the return here is a good idea. I know it's there to avoid multiple errors on the same node, but it also ignores everything else that's nested:

// tslint:disable-next-line (I intentionally dont'want errors on this line)
just().do().stuff(
    // Unfortunately I don't get an error on the nested expression :(
    some().really().long().method().chain()
);

&& isPropertyAccessExpression(node.expression)

does the same with less work:

const rawExpressionText = sourceFile.text.substring((node.expression as ts.PropertyAccessExpression).expression.end, node.end);

I don't consider one method call a chain. Either always use a minimum of 2 or make the threshold configurable

Greatly simplified version, should work too:

function needsNewline(node: ts.PropertyAccessExpression, sourceFile: ts.SourceFile): boolean {
    return !isSameLine(sourceFile, node.expression.end, node.name.pos);
}

Does it make sense to include the dot in the error's range?
That makes more sense if the dot is on the previous line:

foo.
    bar().
    baz();

Would be as simple as

this.addFailure(node.expression.name.pos - 1, node.expression.name.end, Rule.FAILURE_STRING);

ts.forEachChild is not the right choice here. The implementation would complain about this:

this.foo(bar());

Instead you can just recurse into the AST by accessing the expression property:

function hasChildCall(node: ts.PropertyAccessExpression): boolean {
    let {expression} = node;
    while (isPropertyAccessExpression(expression) || isElementAccessExpression(expression)) {
        ({expression} = expression);
    }
    return expression.kind === ts.SyntaxKind.CallExpression;
}

also note that you need to handle ElementAccessExpression for cases like this:

this.getFoo()[0].toString();

I see you already kinda did it this way. I was confused by the closure and the call to forEachChild.
As noted above, forEachChild is wrong here. And once you get rid of it, you don't need the callback. So you will end up with a loop like my example code.

if you return true here, forEachChild will return early without visiting the remaining children.
you could then use return ts.forEachChild(node, checkForCall) === true below

this line will not be reached for CallExpression
but the assertion is unnecessary anyway

nevermind, misread your code

please add the two test cases from my comment above

and in addition:

this.foo()["bar"](); // no error here
foo().bar(); // error here? the current implementation adds one

please revert this change